Typical software maintenance carried by the service companies mainly involves corrective and adaptive maintenance (as defined in ISO/IEC 14764) usually in a T&M model. The differentiation offered to clients is in terms of pricing, experience and expertise of the maintainers, and the internal process and tools adopted for maintenance. Metrics based on prior maintenance history such as average bug fix cycle time, number of additional bugs introduced are also used as an indicator of the maintenance capability. While these parameters are necessary they are not sufficient to fully articulate the value offered to the customer.
Software maintenance that is purely focused on corrective and adaptive maintenance runs the risk of deteriorating the structural quality of the software. This phenomenon, referred to in the literature as software ageing, makes software very hard to maintain in the future. It is generally accepted that “preventive maintenance” nullifies the deterioration and improve the future maintainability of the software. “Preventive maintenance” involves activities that improve the structure of the software so that it is more maintainable without modifying the externally observable behavior. Software restructuring and refactoring are the activities that are generally considered to be part of preventive maintenance.
The present technology can help in demonstrating the value of the corrective and adaptive maintenance, but are not an indicator of preventive maintenance. Moreover, because of the maturity of the IT services industry, the differentiation between the various companies in terms of these parameters has come down. Lastly, a major limitation is that since the present technology does not quantify the amount of preventive maintenance done, they are not good indicators of long term software maintenance quality.
Recently, software ageing and the problem of software maintenance has received much attention and preventive maintenance is increasingly being considered as a key component of software maintenance. However, there does not exist any technology for quantitatively showing the amount of preventive maintenance carried out.
One of the key enablers for preventive maintenance is software modularization, which improves the maintainability of software systems. Software modularization is the restructuring of the software system as a set of modules with well defined APIs, adhering to a set of modularity principles.
Software modularization has been an active area of research and number of approaches have been published in literature on modularizing software systems. Most of these approaches deal with automated approaches for splitting a monolithic code base by grouping logically related files into modules. For solving this problem, a number of approaches have been tried out in literature. These include techniques based on software clustering, graph partitioning, concept analysis, program analysis, meta-heuristic search based optimization, information theoretic, and association rule mining. However, as indicated recently by Maqbool and Babri (Maqbool and H. A. Babri, “Hierarchical clustering for software architecture recovery,” IEEE Transactions on Software Engineering, vol. 33, no. 11, pp. 759-780, 2007.), completely automated software modularization is still very much an unsolved problem.
While discussing the problem of software modularization, Rama argues that the modularization needs of all system are not the same and categorizes systems into three main categories. (G. Maskeri Rama, “A Desiderata for Refactoring-Based Software Modularity Improvement,” in India Software Engineering Conference, ISEC 2010, February 2010.). Monolithic Systems that have no modular structure at all belong to the first category. The primary need of these systems, addressed predominantly by the existing work mentioned above, is the automated support for decomposing the monolithic code into modules. Systems that were initially designed in a modular fashion but having degraded over years of maintenance, still have some degree of modular structure belong to the second category. The primary need of these systems is the incremental improvement in modularity in some modules along with module decomposition. Lastly, newer systems that are starting to show signs of degradation are classified as belonging to the third category. These systems rarely have the need to split monolithic code into modules and more often the requirement is to improve the modularity without drastic change to the existing modular structure. The above work, however, does not mention what specific activities can be used to improve the modularity or the most common recurring activities during modularization of typical systems.
The concept of modularity and modularity operators are discussed in the work of Baldwin and Clark on the economic theory of modularity. (C. Baldwin and K. Clark, Design Rules vol. 1: The Power of Modularity. Cambridge, Mass.: MIT Press, 2000.). Baldwin and Clark examine the impact of the modular approach on the design process of computer systems generally from an economic perspective. Using options theory, Baldwin and Clark model the economic value of modularization, and formalize the evolution of modular systems as the actions of six modular operators:
Splitting: Splitting a module into several smaller modules.
Substitution: Substituting one module by an functionally equivalent module. This allows “competition” between multiple versions of a given module.
Augmentation: Adding a new module to an existing modular system.
Exclusion: Removing a module from an existing modular system.
Inversion: Taking low-level but much-replicated functions and moving them up the module hierarchy, thus increasing their visibility.
Porting: Removing the dependence of modules on a given external system, and adding proxy modules.
While there exists an intuitive understanding of the common activities that are carried out during modularization, such as the work by Baldwin et al., they are not formally and unambiguously defined. As a result, it cannot be automatically determined from the source code whether any structural improvement has been done or not.